home *** CD-ROM | disk | FTP | other *** search
/ TOS Silver 2000 / TOS Silver 2000.iso / programm / MM2_DEV / PATH_ENV / ENVIRONM.TXT < prev    next >
Encoding:
Text File  |  1990-02-03  |  2.8 KB  |  63 lines
  1.  
  2. Überlegungen zum Paths-Modul, HomePath und Programm-Environment
  3. ---------------------------------------------------------------
  4.  
  5. Jedes gelinkte Programm hat eine eigene Umgebung:
  6.   - HomePath mit dazu relativ gelegenen Zusatzdateien
  7.   - Stacksize
  8.   - Treibermodule, z.B. Error-Handler & IO-Treiber, auch Treiber, der
  9.     lediglich auf Taste am Ende wartet & Real-Treiber
  10.  
  11. Genau diese Umgebung muß auch bei Modulen, die unter der Shell gestartet
  12. werden, geschaffen werden.
  13.  
  14. Zur Definition des Umgebungsfelds werden die MSP-Dateien verwendet.
  15. Sie bestimmen dann:
  16.   - Main-Module
  17.   - HomePath des Main
  18.   - Stacksize
  19.   - Treiber-Module, bzw. Konfiguration, die sonst die Treiber erzeugen
  20.     (z.B. I/O-Modus: GEM oder TOS)
  21.   - Ggf. globale Compileroptions, z.B. f. Range-Check, Debugging, usw.
  22.  
  23. Es soll möglich sein, hierzu spezifische Impl-Module von den allg. Modulen
  24. zu trennen. Die spezifischen Module dürften z.B. in ein anderes Dir
  25. (alle ins selbe) als die allg. Code geschrieben werden. Dies müßte anhand
  26. der Vorkommen der Sourcen in verschiedenen Dirs erkennbar sein.
  27. Z.B. könnte man im Umgebungsfeld Source-Dirs definieren, die speziell zu
  28. dem Projekt gehören.
  29.  
  30. Die Frage stellt sich dann, was mit anderen Modulen geschehen soll, die
  31. unter dieser Umgebung gestartet werden.
  32.   - Zum Teil sind die Utilities, bei denen das egal ist: Compiler, Editor,
  33.     PathEdit, usw
  34.   - Das projektbezogene Modul sollte nur über eine spezielle Funktion
  35.     ausführbar sein - so kan die Shell diesen Start von anderen Modulen
  36.     unterscheiden. Bei den anderen Modulen sollte dann ggf. eine Std-
  37.     Umgebung einstellbar sein, z.B:
  38.       - Flag: Akt. Dir erhalten oder auf Origin-Pfad vom Prg setzen
  39.       - Stacksize
  40.  
  41. Noch besser wäre es, wenn von vornherein jedes startbare Modul eine
  42. extra Umgebung erhalten kann, wie gelinkte Programme. Dann könnte
  43. umgekehrt auch der Linker daraus die erforderlichen Daten (Stack,
  44. Treiber, usw) ermitteln.
  45.  
  46. Die Frage ist nur, wie diese Umgebung zu finden ist.
  47. - Entweder ist std-mäßig zu jedem ausführbaren Code optional ein
  48.   Environment-File erstellbar, das dann z.B. von der Shell gesucht
  49.   wird (abhängig vom Dateinamen mit anderer Endung, z.B. "ENV" o. "M2E"),
  50.   ggf. könnte auch dessen Name im Code abgelegt werden.
  51. - Oder im Code wird direkt die Infomation mit abgelegt. dann müßte sie
  52.   schon beim compilieren bestimmt werden, z.b. über optionen in der shell.
  53.   dies ist aber wohl zu aufwendig und unflexibel.
  54. Ist keine Umgebungsinfo vorhanden, wird eine default-einstellung (wie bisher)
  55. verwendet.
  56. Nach diesem Konzept müßte dann aber das bisherige mit den MSP-Dateien (f.
  57. Projekte) geändert werden, denn bei den MSP wird ja ein Teil des Env. schon
  58. global definiert, eher müßte dort die spezielle Env-Datei des Main-files
  59. eingestellt werden oder über dialoge erstellt werden.
  60.  
  61.  
  62. EOT
  63.